DWH 2

OLTP (англ. Online Transaction Processing) или реляционные БД- это базы данных, которые используются везде и повсеместно. Их основная цель - ввод/редактирование/удаление данных в режиме онлайн. Примеры использования: мессенджеры, социальные сети, 1С: Бухгалтерия и т.д.

OLAP (англ. Online Analytical Processing) или многомерные БД - это базы данных, которые служат непосредственно для проведения быстрого анализа больших объемов данных. Обычно такие БД используются на больших предприятиях для построения аналитической отчетности за большой промежуток времени (месяц, квартал, год). Такая информация в основном используется для анализа прошедшего периода и планирования будущего. Основные пользователи аналитических данных - руководители.

В базах данных OLAP в центре находится таблица фактов, в которой находятся все показатели (сумма, кол-во) и ссылки на справочники.

А в OLTP одна таблица цепляется за другую без наличия общего связующего звена.

Практический пример, почему для аналитики лучше использовать OLAP.

Допустим, мы хотим найти клиентов, которые совершили больше всего покупок (в денежном эквиваленте), чтобы дать им скидку на будущие покупки.

Если использовать OLTP систему, то нужно использовать справочники:

Клиент - Заказ - Заказанный товар - Товар - Цена на товар

Если воспользоваться OLAP, то понадобится только:

Таблица фактов - Клиент - Цена на товар.

Количество используемых таблиц меньше, производительность лучше, скорость выше.

В OLAP делать insert гораздо сложнее, чем в OLTP

На примере описанном выше попробуем разобраться, как добавить новый заказ в OLAP и OLTP.

В OLTP нужно заполнить 2 таблицы Заказ и Заказанный товар. Для этого необходимо:

1. найти или добавить нового клиента, который сделал заказ, в таблице Клиент

2. найти сотрудника, который составил заказ в таблице Сотрудник

3. добавить запись в таблицу Заказ

4. найти артикул товара в таблице Товаров

5. добавить запись в таблицу Заказанный товар

Итого в запросе базы OLTP будет использоваться 5 таблиц.

В OLAP нужно заполнить только одну таблицу Фактов, но для этого нужно выбрать значения ИД всех справочников:

1. найти или добавить нового клиента в таблице Клиент

2. найти сотрудника в таблице Сотрудник

3. добавить заказ в таблицу Заказ

4. найти товар в таблице Товар

5. найти цену на товар, актуальную на дату составления заказа, в таблице Цена на товар

6. найти склад, на котором хранится товар, в таблице Склад

7. вставить запись в таблицу Фактов.

Итого в запросе базы OLAP будет использоваться 7 таблиц.

---

Что такое факты и измерения в хранилище данных?

Факты и измерения (facts and dimensions) — это фундаментальные элементы, определяющие хранилище данных. Они фиксируют соответствующие события предметной или функциональной области (факты) и определяющие их характеристики (измерения).

Хранилища данных — это системы хранения и поиска данных (т. е. базы данных), специально разработанные для поддержки деятельности бизнес-аналитики (BI) и OLAP (аналитическая онлайн-обработка). Они отличаются от баз данных, предназначенных для поддержки транзакционных систем (например, сайтов электронной коммерции), функция которых в первую очередь заключается в OLTP (онлайн-обработка транзакций).

Хранилища данных обычно содержат большие объемы исторической информации для выполнения запросов и анализа. Информация в хранилище данных также часто поступает из самых разных источников и используется в запросах, которые перекрестно ссылаются на информацию из разных источников для открытий и получения ценной информации.

Основное преимущество хранилища данных заключается в извлечении значительной пользы из информации, накопленной с течением времени. Организации в значительной степени зависят от своих хранилищ данных в плане фундаментальной поддержки при принятии решений. К проектированию хранилища данных не следует относиться легкомысленно из-за его ценности для организации, и как только оно начинает заполняться данными, изменение его структуры становится очень рискованным и потенциально дорогостоящим.

Четыре столпа хранилища данных

Уильям Инмон, один из предшественников концепции хранилища данных, указывает, что хранилища данных характеризуются четырьмя фундаментальными условиями:

• Ориентированы на один предмет или определенную функциональную область. Например, он ориентирован на продажи компании.
• Они унифицируют и обеспечивают согласованность данных из разрозненных источников.
• Стойкий и неизменный. Как только данные попадают в хранилище данных, они остаются там и не изменяются.
• Структурировано по временным интервалам. Чтобы предоставить информацию с исторической точки зрения, хранилища данных записывают информацию через разные промежутки времени, например еженедельно, ежемесячно, ежеквартально и т. д.

Хорошо спроектированное хранилище данных отличается высокой производительностью и оперативно реагирует на запросы. Это также обеспечивает гибкость, позволяющую бизнес-аналитикам (или любому другому конечному пользователю хранилища данных) запрашивать данные с разных точек зрения. Пользователи могут по своему желанию переключаться между общим обзором и глубокими запросами с максимальной степенью детализации.

Хранилище данных служит источником информации для инструментов BI-визуализации. Он предоставляет конечным пользователям возможность легко создавать отчеты, информационные панели, графики и другие формы запроса данных.

---

С технической точки зрения хранилище данных — это база данных. Следовательно, она состоит из таблиц, полей, связей и ключей – как и любая другая база данных. Таким образом, вы можете смоделировать его с помощью инструмента проектирования баз данных.

Однако таблицы хранилища данных имеют некоторые особенности, отличающие их от таблиц, обычно используемых для обработки транзакций. В частности, таблицы хранилища данных делятся на две основные категории: таблицы фактов и таблицы измерений.

Факты и измерения в хранилище данных должны формировать макет, соответствующий определенной топологии. Существует две основные топологии: СХЕМА ЗВЕЗДА и СХЕМА СНЕЖИНКА. В схеме «звезда» отдельные измерения окружают одну таблицу фактов, тогда как схема «снежинка» имеет иерархию измерений.

Типичная звездообразная схема хранилища данных: таблица фактов находится посередине, окруженная таблицами измерений.

---

Размеры и факты

Факты — это измеримые события, относящиеся к функциональной области, охватываемой хранилищем данных. Например, продажи — это факты в хранилище данных для области продаж и распространения компании. Если хранилище данных содержит информацию об уходе за пациентами в больнице, визиты пациентов в больницу являются фактами.

Таблицы фактов — это основные таблицы хранилища данных. Они содержат количественную информацию, обычно связанную с моментами времени. Они используются в тенденциях, сравнениях, агрегированиях и группировках. Они предоставляют инструменты анализа и визуализации, позволяющие получить представление о функциональной области.

С другой стороны, измерения представляют собой наборы справочной информации о фактах в хранилище данных. Измерения классифицируют и описывают факты, записанные в хранилище данных, чтобы предоставить значимые, категоризированные и описательные ответы на бизнес-вопросы.

При проектировании хранилища данных обычно сначала создаются таблицы измерений, а затем таблицы фактов, связывая их с таблицами измерений через внешние ключи. По этой причине давайте сначала посмотрим, что такое таблицы измерений и как они классифицируются.

Определение таблиц измерений

Как и большинство таблиц в реляционной модели, таблицы измерений имеют первичный ключ, который может быть естественным или суррогатным, и набор атрибутов. Однако таблицы измерений не обязательно должны находиться в третьей нормальной форме, чтобы выполнять свою работу. Фактически, для повышения производительности запросов допускается существование зависимостей между неключевыми атрибутами таблицы измерений, чтобы минимизировать количество таблиц, которые необходимо объединить в запросе.

Таблицы измерений имеют низкую мощность и относительно небольшое количество строк, поэтому их влияние на производительность минимально. Они также имеют множество атрибутов, которые в основном являются текстовыми или временными. Размеры хранилища данных вместе с их атрибутами служат рекомендациями для аналитиков данных, позволяющими просматривать информацию под разными углами и применять разные критерии фильтрации.

Типы измерений

Размеры хранилища данных подразделяются на различные типы в зависимости от их поведения и использования. При проектировании таблиц в хранилище данных знание типа каждого измерения помогает принять правильные проектные решения.

Существует множество типов размеров. Ниже мы увидим только четыре из них: согласованные измерения (Conformed Dimensions), ролевые измерения (Role-Playing Dimensions), медленно меняющиеся измерения (Slowly-Changing Dimensions (SCDs)) и мусорные измерения (Junk Dimensions).

Conformed Dimensions

Согласованное измерение может быть связано с различными таблицами фактов, сохраняя для всех них одно и то же значение. В хранилищах данных типа созвездия с несколькими таблицами фактов согласованные измерения делают возможными междоменные запросы.

Типичным согласованным измерением является дата. Его значение не зависит от таблицы фактов. По этой причине большинство хранилищ данных имеют одно измерение даты, общее для всех таблиц фактов.

Другие согласованные размеры не так очевидны, как дата, и могут создавать проблемы при проектировании, поскольку им необходимо обеспечить согласованность в различных областях. Источники данных в согласованном измерении могут иметь структурные различия между собой, например отсутствующие или дополнительные столбцы, столбцы с разными типами данных и столбцы с разными именами, представляющие одни и те же данные.

Примером может служить измерение SKU (артикул), общее для таблицы фактов покупок и таблицы фактов продаж. Использование SKU в качестве согласованного измерения требует сбора атрибутов измерения, поступающих из обоих доменов, в одну таблицу и создания общих типов данных и имен атрибутов для обоих.

Role-Playing Dimensions

Ролевые измерения используются в разных таблицах фактов, как и согласованные измерения. Но в отличие от согласованных измерений они имеют разные значения в зависимости от таблицы фактов или даже поля в таблице фактов.

Измерение даты, упомянутое ранее как согласованное измерение, может быть ролевым измерением, если мы связываем одну и ту же таблицу с разными атрибутами даты. Например, в таблице фактов продаж у нас могут быть дата заказа, дата поставки и дата платежа, связанные с одним и тем же измерением даты.

Slowly-Changing Dimensions (SCDs)

Одно из различий между событиями и измерениями заключается в том, что события происходят один раз и оставляют запись о том, что они произошли. Эта запись останется там навсегда, без шансов на ее изменение.

С другой стороны, размеры могут измениться. Атрибуты SKU, некоторые данные о клиентах и даже названия, казалось бы, неизменных вещей, таких как места или учреждения, могут измениться. Измерения, которые подвержены изменениям, называются медленно изменяющимися измерениями (SCD). Здесь «медленно» является субъективным; точнее было бы назвать их просто изменением размеров.

При проектировании хранилища данных необходимо подумать о том, как эти изменения повлияют на таблицы измерений, поскольку изменения в измерениях этого типа неизбежны. К счастью, те, кто уже столкнулся с этой дилеммой, разработали ряд стратегий, позволяющих поддерживать SCD в актуальном состоянии.

При определении SCD мы должны решить, какую стратегию обновления применить. Наиболее распространенными стратегиями обновления являются:

• Нет обновления. Эта стратегия применяется к неизменяемым измерениям, таким как большинство измерений типа даты.
• Атрибуты всегда обновляются до самого последнего значения. Все события, относящиеся к измерению, связаны с самыми последними значениями его атрибутов, независимо от того, когда они происходят.
• Изменения измерения применяются путем создания новых версий измененных элементов либо путем добавления записей, включающих дату вступления в силу, либо с помощью таблиц истории, либо путем добавления полей, позволяющих отличать новые данные от исходных данных.

Junk Dimensions

При проектировании хранилища данных факты часто имеют индикаторные атрибуты, такие как флаги, логические значения или какой-либо другой набор значений, которые не имеют смысла в качестве измерения из-за их низкой мощности. Чтобы избежать создания маленьких измерений для каждого из этих атрибутов и ненужного увеличения количества и размеров таблиц фактов, часто создается ненужное измерение, чтобы собрать все эти атрибуты в одну таблицу.

Он собирает все возможные комбинации охватываемых им атрибутов, идентифицируя каждую комбинацию с помощью одного суррогатного первичного ключа. В таблице фактов достаточно включить один внешний ключ в таблицу ненужных измерений вместо хранения значения каждого из атрибутов. Чтобы прояснить эту идею, давайте рассмотрим пример.

данные:

Тогда наша таблица фактов может иметь такую структуру:

В зависимости от комбинации ненужных измерений для каждого факта вы назначаете значение JunkId, соответствующее строкам с одинаковой комбинацией значений.

Определение таблиц фактов

В таблицах фактов существует два типа атрибутов: качественные и количественные. Качественные атрибуты определяют характеристики факта; они обычно определяются как внешний ключ к таблице измерений. Количественный атрибут определяет меру факта: сумму, величину, продолжительность времени или любую другую измеримую (числовую) величину, к которой можно применить статистические вычисления, такие как сумма, среднее значение и дисперсия.

Меры могут быть аддитивными или неаддитивными в зависимости от того, можно ли их суммировать по какому-либо измерению. Они также могут быть полуаддитивными, то есть их можно суммировать по некоторым измерениям хранилища данных.

Мы можем классифицировать таблицы фактов на три категории в зависимости от того, как записываются показатели:

• Таблицы транзакционных фактов. В таблицах фактов транзакций каждая строка соответствует элементу транзакции. Например, если события, записанные в таблице, являются счетами-фактурами, каждая строка таблицы содержит информацию об одной позиции счета-фактуры. Таблицы транзакционных событий стремятся записывать как можно больше деталей, поэтому они обычно включают большое количество измерений.
• Периодические снимки: таблицы фактов периодических снимков делают снимки событий за заданные периоды времени. В качестве источника информации они обычно используют таблицы фактов транзакционного типа. Например, они записывают общий объем продаж за день путем суммирования данных из таблицы фактов транзакционных продаж.
• Совокупные снимки. Таблицы фактов совокупных снимков используются для обозначения различных этапов бизнес-процесса, обычно с несколькими столбцами дат. Каждая строка таблицы фактов суммирует события, произошедшие между началом и завершением процесса. Таблицы этого типа полезны для хранилищ данных, которые собирают информацию из конвейерных процессов, таких как обработка претензий и выполнение заказов. Каждая строка таблицы фактов совокупного снимка соответствует событию в соответствующем бизнес-процессе. В качестве примера возьмем заявки на заявки – при изменении статуса заявки даты и время изменения статуса записываются в соответствующую запись таблицы фактов, сопровождаемую показателями прошедшего времени и задержек.

Детализация фактов

Детализация данных таблицы фактов определяет максимально возможный уровень детализации при анализе информации в хранилище данных. Более детальные данные обеспечивают более высокий уровень детализации, но это также подразумевает большее количество измерений, большее хранилище данных и большую сложность запросов и процессов сбора данных.

Степень детализации таблиц фактов — одно из наиболее важных решений при проектировании хранилища данных, поскольку оно определяет размеры и способ записи событий в таблицах фактов. После того как хранилище данных спроектировано и запущено, изменение структуры таблиц фактов становится практически невозможным из-за затрат усилий, времени и затрат.

Точно так же, как сложно изменить организацию большого физического склада материалов и продуктов, сложно изменить структуру большого хранилища данных. Чтобы избежать непреодолимых ошибок при работе с хранилищем данных, крайне важно с самого начала точно определить два его основных элемента: факты и измерения.